@turbokongen, thanks for your PR! By analyzing the history of the files in this pull request, we identified @armills, @balloob and @andrey-git to be potential reviewers.

On HA restart the poll value will get back to the config setting

Yes, we can ofcourse remove everything all together, and make every config that has polling_intensity set fail, or we can leave both, and let users migrate. I can add a warning to be printed for each config line set.
Is that a usable solution?

I don't see a migration path here.
Things shouldn't change on restart and creating a start-up automation that will call a service is too cumbersome.

Why have this runtime-controlled anyway?

Isn't it wanted to be able to set/remove polling without a restart of the whole server?

It is definetly a plus, but if the value is not retained across a restart, then it's a step back.

You are completely right @andrey-git
I forgot about the hard setting that was already present in the code.
It's now removed.

OK, this is better now.
This makes backing up zwcfg even more important, as another piece of info is now stored there.

@turbokongen @andrey-git please consider the following possible scenario: a system crashes for whatever reasons. With automatic deployments u redeploy the app very simple and have everything working again instantly; by moving configuration things to UI (like u did with the entire zwave node id namings) which indeed need to be setup only once in the UI) u're asking that user to reconfigure manually from UI everything.

You're moving from hardcoded controllable configuration deployed files used in automated deployments to manual labor configurations from UI.

Is this the wanted behavior and/or direction ?

@rofrantz All the information you mention is stored in zwcfg[home_id].xml
So a backup of that file will restore the data. Just like copying back the configuration.yaml restores the settings.

Thanks @turbokongen that's indeed a solution too.
I prefered to avoid it since I didn't want get dirty with the content of that file...u know and I know how it looks and what it contains compared to the nice looking dedicated yaml config file which is more human readable, not to mention it contained only the data I care about and not 10000 zwave params and configs.

But I guess that will work.
Thanks for your feedback

Another point is that configuration.yaml doesn't get corrupted easily as it is written only on user action.
If you change a value in the UI (that should go into zwcfg) you basically need to restart anyway in order to write the data to zwcfg, otherwise if HA doesn't go down gracefully (blackout?) the change will be lost.

That's also the reason I disliked the IDs change - I don't want to depend on zwcfg.

@andrey-git I didn't wanna raise the dead, but as @turbokongen once said "it is decided, and it is done" :)

Since zwave devices have only a handful config attributes and two of them (ignore and poll) are already in UI config editor, I think a better solution would be to implement the rest of them in the UI.

That said, changing poll interval should also call the new service - updating the device live, but in addition saving this into the config, thus not relying on zwcfg.

I'm torn in how to implement this. To be able to do both the live and the config file updates, we need the entity_id together with the value_id. I can't seem to find one place where both are present, so this first draft is accessing a protected member to generate the entity_id in the value-view api. Please comment and suggest, as this is the best I could come up with at this moment. 😢

Ping?

So if I understand correctly:

For users who have poll intensity defined in the config: Using the UI will take effect but on restart it will fall back to the config value.

For users without poll intensity in the config: Poll intensity is stored in zwcfg

Why can't we do both, we store it both in the config and make it take effect right away? And in the future we add a checkbox to do it temporarily only (and not write it to config).

When using the Frontend editor, it sets both the live value and saves to the configuration. If only using the service, that is temporary.